A software thread is a stream of instructions that are to be executed by a processor. As known to those skilled in the art, when a software thread is placed in a sleep state, the thread is deactivated by a scheduler and the thread is then re-activated when a given external event occurs such as, for example, the expiration of the sleep time period or when a currently running thread issues a wakeup call to the sleeping thread. Note that in other systems, the “sleep state” is alternatively called a “waiting state” or “suspended state”. In the sleep state, the thread is typically placed in a queue (“sleep queue”) of threads waiting for a lock (i.e., synchronization object). When a thread is placed in the sleep state, the thread does not consume a significant amount of processor time. A lock is associated with a shared resource (e.g., a CPU core) so that other threads will be blocked from accessing the shared resource until a currently running thread has completed its operation in the shared resource and has released the lock.
When a particular thread has to wait for a shared resource because a currently running thread is using that shared resource, the particular thread will go into the sleep state. When the resource becomes available because the currently running thread has released the lock for the resource, the currently running thread will issue a wake-up call to the sleeping thread (i.e., the thread in a sleep state). When the sleeping thread is woken up, the scheduler places the woken-up thread on a run queue. The scheduler can then pick up the woken-up thread in the run queue and execute that thread. However, this woken-up thread is unable to run at least until a currently running thread on the processor is switched out by the scheduler. The wait time for this woken-up thread to run may vary, depending on the run queue load (i.e., the number of threads that are ahead of the woken-up thread in the run queue) and the relative priorities of the threads that are already in the run queue.
One problem that may occur is that a resource may be available (i.e., the resource is in an unlocked-state) for use by threads, but only the woken-up thread is permitted to acquire this available resource. No other thread other than the woken-up thread can acquire this resource. As mentioned above, this woken-up thread may also be waiting in the run queue and waiting its turn to run until other appropriate threads in the queue have run. In this circumstance, it is important that the woken-up thread runs as soon as possible and use the resource that only the woken-up thread can acquire, so that unnecessary contention on that resource by threads and wasted CPU (central processing unit) consumption are reduced. For example, this additional contention is due to the woken-up thread contending with other threads for a global lock before the woken-up thread can obtain a resource-specific lock for that resource. Current approaches do not provide a solution to the above-discussed problem. For example, one possible approach is to increase the priority of the woken-up thread so that the wait time in the run queue of the woken-up thread is reduced. However, this approach is expensive in terms of additional hardware and software overhead, and does not always lead to a significant reduction in the wait time in the run queue of the woken-up thread.
Therefore, the current technology is limited in its capabilities and suffers from at least the above constraints and deficiencies.